Device and method for providing trusted platform module services

ABSTRACT

The invention concerns a circuit having a first processing device which has one or more first platform configuration registers for storing one or more data values based on boot measurements relating to a boot sequence implemented by the first processing device. The first processing device also has a secure element, which has its own processing device and one or more second platform configuration registers. The first and second platform configuration registers are coupled together via a communications interface adapted to copy the one or more data values from the one or more first platform configuration registers to the one or more second platform configuration registers.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application claims the priority benefit of French Patentapplication number 14/57855, filed on Aug. 18, 2014, the content ofwhich is hereby incorporated by reference in its entirety to the maximumextent allowable by law.

BACKGROUND

Technical Field

The present disclosure relates to the field of methods and devices forproviding trusted platform module (TPM) services, without using adedicated TPM device.

Description of the Related Art

In order to provide the authenticity and security of hardware andsoftware configurations, it has been proposed to use a trusted platformmodule (TPM). A TPM is a cryptographic device for enabling trustedcomputing. One key requirement of a trusted computing environment is toensure the integrity of the boot sequence. To do this, the TPM forms a“root of trust”. In particular, from power-on of a computing device, theboot sequence starts from a trusted condition, and this trust isextended until the operating system has fully booted and applicationsare running. The integrity is ensured at each step by using one or moreplatform configuration registers (PCRs) of the TPM to securely storeboot measurements. The contents of the PCRs can then becryptographically signed by the TPM and provided to an application orremote party such that the integrity of the boot sequence can beverified.

Trusted platform modules may be incorporated into a wide range ofelectronic computing devices, including smartphones, tablet computersand laptop computers. They are generally implemented as hardware devicescoupled to the main processor of the electronics device.

However, due to limits on available chip area and power, for manyapplications such as smartphones or other portable devices, there is aneed for a solution for providing TPM services without using a dedicatedTPM device. There are, however, technical difficulties in providing sucha system while providing high security and fast response times.

BRIEF SUMMARY

Embodiments of the present disclosure at least partially address one ormore needs in the prior art.

According to one aspect, there is provided a circuit comprising: a firstprocessing device including one or more first platform configurationregisters storing one or more data values based on boot measurementsrelating to a boot sequence implemented by the first processing device;and a secure element including a second processing device and one ormore second platform configuration registers, the first and secondplatform configuration registers being coupled together via acommunications interface adapted to copy the one or more data valuesfrom the one or more first platform configuration registers to the oneor more second platform configuration registers.

According to one embodiment, the secure element is further adapted toimplement at least one cryptographic function for authentication of auser of the circuit.

According to one embodiment, the first processing device comprises atrusted execution environment in which the one or more first platformconfiguration registers are stored.

According to one embodiment, the circuit further comprises a memorystoring one or more first software applications adapted to verify theintegrity of the boot sequence based on the one or more data values.

According to one embodiment, the secure element further comprises amemory storing one or more second software applications for facilitatingthe transmission of the one or more boot measurements to the one or morefirst software applications.

According to one embodiment, the circuit further comprises one or moredrivers for facilitating the transmission of the one or more bootmeasurements to the one or more first software applications.

According to one embodiment, the secure element is adapted tocryptographically sign the one or more data values and to provide thecryptographically signed data values to a requesting element.

According to one embodiment, the secure element comprises a memorystoring a third software application executable by the second processingdevice for cryptographically signing the one or more data values.

According to one embodiment, the circuit is adapted to authorize orrefuse one or more transactions based on said one or more data values.

According to a further aspect, there is provided a smartphone comprisingthe above circuit.

According to a further aspect, there is provided a method of verifyingthe integrity of a boot sequence comprising: implementing a bootsequence by a first processing device; storing, in one or more firstplatform configuration registers of the first processing device, one ormore data values based on boot measurements relating to the bootsequence; transferring one or more data values from the one or morefirst platform configuration registers to one or more second platformconfiguration registers of a secure element having a second processingdevice, the first and second platform configuration registers beingcoupled together via a communications interface.

According to one embodiment, the method further comprises: requesting,by a first software application, the one or more data values;cryptographically signing the one or more data values by the secureelement; and providing, by the secure element, the one or morecryptographically signed data values to the first software application.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The foregoing and other features and advantages will become apparentfrom the following detailed description of embodiments, given by way ofillustration and not limitation. Non-limiting and non-exhaustiveembodiments are described with reference to the following drawings,wherein like labels refer to like parts throughout the various viewsunless otherwise specified. One or more embodiments are describedhereinafter with reference to the accompanying drawings in which:

FIG. 1 schematically illustrates services provided by TPM according toan example embodiment;

FIG. 2 schematically illustrates a printed circuit board of a computingdevice according to an example embodiment;

FIG. 3 schematically illustrates a portion of a computing device forproviding TPM services according to an example embodiment of the presentdisclosure; and

FIG. 4 is a flow diagram illustrating operations in a method ofverifying the integrity of a boot sequence according to an exampleembodiment of the present disclosure.

DETAILED DESCRIPTION

FIG. 1 schematically represents a TPM system 100 implementing a processof platform integrity verification provided by a Trusted Platform Module(TPM) implemented in this example by a dedicated cryptographic device100.

A BIOS (basic input output system) boot block (BIOS BOOT BLOCK) 102 forexample comprises a non-volatile memory such as a ROM, and provides aroot of trust for integrity verification. As represented by an arrowbetween the BIOS boot block 102 and the TPM 100, one or more bootmeasurements corresponding to the BIOS boot block 102 may be transmittedto the TPM 100.

Nodes 104, 108, 110 and 112 in FIG. 1 represent software that is loadedto volatile memory, such as a RAM (random access memory), during theboot sequence. The BIOS boot block 102 for example causes a BIOS 104 tobe loaded into a volatile memory. As represented by an arrow between theBIOS 104 and the TPM 100, one or more boot measurements associated withthe loading of the BIOS 102 may be transmitted to the TPM 100 by theBIOS 102. Furthermore, one or more auxiliary hardware components(HARDWARE) 106 included in the platform, such as a graphics card, acontroller managing the platform connectivity or a cryptographiccoprocessor, may also be booted in response to the loading of the BIOS104. The microcode running on these components may also be measured andtransmitted to the TPM.

An operating system loader (OS LOADER) 108 is then for example loadedfrom non-volatile memory to volatile memory, and again one or more bootmeasurements may be transmitted to the TPM 100.

An operating system (OS) 110 is then for example loaded fromnon-volatile memory to volatile memory, and again one or more bootmeasurements may be transmitted to the TPM 100.

One or more software applications (APPLICATION) 112 are then for exampleloaded from non-volatile memory, and again one or more boot measurementsmay be transmitted to the TPM 100.

The trusted platform module 100 comprises a bank 114 of one or moreplatform configuration registers (PCRs), and the boot measurementsgenerated during the boot sequence are stored in this register bank.Generally, after reset, the PCR bank 114 stores a null value, and theboot measurements can for example only be stored in the PCR bank 114using an “extend” instruction to extend the contents of the PCR bank. Atthe end of the boot sequence, the one or more PCRs 114 for example eachcontain a digest of the chained measurements of the booted software. Inone example, each measurement transmitted to a specific PCR updates thePCR value with the formula PCR_NEW=H(PCR_OLD+M), where PCR_NEW is theupdated PCR value, PCR_OLD is the previous PCR value, M is themeasurement, and H( ) is a digest function. Thus the final PCR value atthe end of the boot process is a digest of all measurements transmittedto the TPM. This final PCR value can only be reached by transmitting tothe PCR the same specific measurements in the same order.

The TPM 100 for example comprises cryptographic functions that allow themeasurements stored in the PCR bank 114 to be cryptographically signed.As represented by an arrow 116, the cryptographically signedmeasurements may be provided to one or more requesting parties, such asthe operating system 110 and/or one of the applications 112, in order toverify the integrity of the boot sequence.

FIG. 2 schematically illustrates a substrate, such as a printed circuitboard (PCB) 200, in which TPM (trusted platform module) services may beprovided.

The PCB 200 includes a system on chip (SoC) 202, which comprises aprocessing device (PROCESSING DEVICE) 203. As will be described in moredetail below, the processing device 203 for example includes a trustedexecution environment permitting processing and storage of sensitivedata. Herein, the term “sensitive data” is used to designate any datathat should remain inaccessible to unauthorized parties.

The SoC 202 is for example coupled to a bus 204 via which processingdevice 203 of the SoC 202 may communicate with other optional hardwareblocks. In the example of FIG. 2, the PCB 200 further comprises anoff-chip SoC processing device (OFF-SoC PROCESSING DEVICE) 206, coupledto the bus 204, which is for example a cryptographic co-processor.Device 206 is for example adapted to execute functions not supported bythe SoC, such as cryptographic functions. As with the processing device203 of the SoC 202, the processing device 206 may include a trustedexecution environment permitting processing and storage of sensitivedata. However, as will become apparent from the description hereafter,the device 206 may advantageously be omitted thanks to the new functionsof the processing device 203 and the secure element 208 and/or 210.

The PCB 200 also for example comprises an embedded secure element (ESE)208 and/or a removable secure element (REMOVABLE SE) 210, each coupledto the bus 204. As known to those skilled in the art, an embedded orremovable secure element provides cryptographic functions forauthenticating a user of the circuit and/or for performing otheroperations such as signature generation.

A real time clock (RTC) 212 is also coupled to the bus 204 and mayprovide time information to platform services.

The PCB 200 also for example comprises a volatile memory 214, such asRAM (random access memory), and/or a non-volatile memory 216, such asFLASH memory 216, coupled to the bus 204. The PCB 200 may also compriseone or more input/output interfaces (I/O INTERFACES) 218 coupled to theSoC 202 and to the bus 204, which for example include video drivers,keyboards, touch screens, etc. The PCB 200 may further comprise a powercontrol circuit (PC) 220, coupled to the SoC 202 and to the bus 204,which controls power-down and power-up of the SoC 202 and/or one or moreother devices on the PCB 200.

As will be described in more detail below, rather than having adedicated TPM device, TPM services provided in the system 100 of FIG. 1are shared between the processing device 203 and one or both of thesecure elements 208 and 210.

FIG. 3 schematically illustrates a portion 300 of a computing device inwhich the functions of a TPM are implemented by a main processing device302 and a secure element 304 of electronics device. In particular, theimplementation of FIG. 3 for example permits at least the verificationof the integrity of a boot sequence. The main processing device 302 isfor example the processing device implementing the boot sequence of thedevice, such as the processing device 203 of the SoC 202 in FIG. 2. Thesecure element 304 could be an embedded secure element, like the element208 of FIG. 2, or a removable secure element, like the element 210 ofFIG. 2.

The processing device 302 includes one or more platform configurationregisters in a bank 306, which are for example held within a trustedexecution environment (TEE) of the processing device 302. As known bythose skilled in the art, a TEE includes hardware and software forisolating certain data and operations from other parts of the device inorder to provide security against software attacks.

The TPM functionality of the processing device 302, which will bediscussed in more detail below, is for example controlled by a TPMsoftware stack (TPM SOFTWARE STACK) 307, which also provides TPMservices to applications running on the platform.

The PCR bank 306 is for example adapted to receive boot measurementsgenerated during the boot sequence of the processing device 302. Thesemeasurements for example correspond to code measurements made duringplatform boot. The boot measurements for example concern the loading ofa BIOS, an operating system, and/or one or more applications. In someembodiments, boot measurements may also be generated in relation to theloading of one or more hardware drivers, thereby adding security to theoperation of such hardware. For example, the boot measurements mayconcern the loading of a display driver, keyboard driver and/or modemdriver, in order to add security to the display of data, to protect dataentered by a user, and/or to protect transaction data.

The secure element 304 comprises one or more further PCR banks 308. Aconnection 310, authenticated using physical or logical protections,links the processing device 302 and the secure element 304, and inparticular couples the PCR bank 306 to the PCR bank 308 to allow datato/from the PCR bank 306 to be transferred from/to the PCR bank 308. Insome embodiments, a transfer is performed each time the PCR bank 306 isextended, such that the PCR bank 308 is constantly maintainedup-to-date. Alternatively, the PCR bank 308 is for example synchronizedonly once at the end of the platform boot process, once the PCR bank 306has received all measurements made by the processing device 302. Indeed,in some cases, the secure element 304 may not be available as quickly asthe processing device 302 during the boot process.

The secure element 304 for example comprises various functional blocksrepresented in FIG. 3, which are for example implemented in softwareexecuted by a processing device of the secure element (not illustratedin FIG. 3). In particular, the secure element comprises a virtualmachine (VM) 312 providing services to applications (applets). In theexample of FIG. 3, the software architecture of the secure element forexample includes the virtual machine 312 in order to allow independentapplication providers to load applets, the virtualization providing afirewall between applets and avoiding conflicts between applets. Thesecure element 304 also comprises a TPM library (TPM LIBRARY) 314,called by the virtual machine, and which comprises code for controllingTPM data and providing TPM services to the virtual machine 312. TPM dataincludes encryption keys cryptographically signing the contents of thePCR bank 308, and/or other relevant data.

The applets of the secure element 304 support communications between thesecure element 304 and one or more other elements that may requestverification of the integrity of the boot sequence implemented by theprocessing device 302. For example, the secure element 304 comprises aJava Card (JC) applet 316 supporting an ISO 7816 communications protocolallowing communications via an ISO 7816 driver (ISO7816 DRIVER) 318 witha TPM software stack (TPM SOFTWARE STACK) 320, which may be the same asthe software stack 307. The standard TPM commands sent by the TPMsoftware stack to the TPM are wrapped by the driver and unwrapped by theJava Card applet 316. Once the commands are unwrapped, the Java Cardapplet 316 can process the TPM commands through the Virtual Machineservice by the TPM library 314.

As represented by an arrow directly between the driver 318 and the TPMlibrary 314, the TPM library 314 may additionally or alternativelyprovide TPM services to the software stack 320 via the driver 318without using the virtual machine layer (applet 316).

Furthermore, a non-ISO 7816 driver (NON-ISO7816 DRIVER) 319 may beprovided between the TPM library 314 and the TPM software stack 320 inaddition to or instead of the driver 318. No applet is used in thisexample between the TPM library 314 and the driver 319. The hardwareconfiguration for example uses an SPI (serial peripheral interface) busor an SWP (single wire protocol) bus between the TPM library 314 and thedriver 318 and/or the driver 319, the bus or buses for example beingshared with the processing device 302.

Additionally or alternatively, the secure element 304 may store a JavaCard applet (APPLET) 322 permitting communications with an application324 using non-standard TPM commands. For example, the integrityverification provided by the data of PCR bank 308 could be used for arange of applications, for example as part of an authentication process.In one embodiment, a digital signature is generated by the secureelement 304 for authenticating a financial transaction, such as theamount, currency and/or destination account. Such a signature forexample additionally comprises data of the PCR bank 308, and this datais verified before authorizing the transaction.

Operation of the circuit of FIG. 3 will now be described in more detailwith reference to the flow diagram of FIG. 4.

In a first operation 402 of FIG. 4, a boot sequence of the processingdevice is initiated. This for example follows a power-down period of theportion 300 of the computing device of FIG. 3, and the boot sequence isfor example automatically launched upon power-up.

In a subsequent operation 404, one or more boot measurement(s) aregenerated during the boot sequence.

In some embodiments, the PCR are stored in a TEE, which is notimmediately available at the start of the boot sequence. In such a case,as shown in an operation 406, until TEE has been loaded, these bootmeasurements may be temporarily stored by the processing device 302,and/or some measurements may be transmitted directly to the secureelement 304 to be stored in the PCR bank 308 as represented by a dashedarrow from operation 406 to an operation 412 discussed below.

In a subsequent operation 408, boot measurements are transmitted to thePCR bank 306 of the processing device 302, for example in a TEE. Theboot measurements are stored in the PCRs as PCR values calculated basedon the boot measurements. As represented by a block 410, one or morefurther boot measurements may be generated during the boot sequence, andadded to the PCR 306 in operation 408.

Furthermore, periodically each time a new boot measurement istransmitted to the PCR 306, or at the end of a boot sequence once allmeasurements have been taken, the boot measurements are copied to thePCR bank 308 of the secure element 304. As described above, the bootmeasurements can then be cryptographically signed and used during averification of the integrity of the boot sequence.

While not illustrated in FIG. 4, the verification of the integrity ofthe boot sequence for example involves comparing one or more bootmeasurements with a reference value. If the boot measurements match thereference value, the boot sequence is for example considered to bevalid.

Advantageously in the embodiments described herein, functions of a TPMare implemented using PCRs of both the processing device executing theboot sequence and a secure element, and the boot measurements aretransferred via a secure connection between the two PCR banks. In thisway, the PCRs of the processing device can be available very rapidlyduring the boot sequence, and the PCRs of the secure element can providea very secure interface with other elements requesting access to theboot measurements.

Having thus described at least one illustrative embodiment, variousalterations, modifications and improvements will readily occur to thoseskilled in the art.

For example, it will be apparent to those skilled in the art that, whileembodiments have been described in which the PCR of the processingdevice is stored in a TEE to provide additional security, such a featureis optional.

Furthermore, it will be apparent to those skilled in the art that thevarious features described in relation to the various embodiments couldbe combined, in alternative embodiments, in any combination.

The various embodiments described above can be combined to providefurther embodiments. These and other changes can be made to theembodiments in light of the above-detailed description. In general, inthe following claims, the terms used should not be construed to limitthe claims to the specific embodiments disclosed in the specificationand the claims, but should be construed to include all possibleembodiments along with the full scope of equivalents to which suchclaims are entitled. Accordingly, the claims are not limited by thedisclosure.

The invention claimed is:
 1. A circuit, comprising: a first processingdevice including one or more hardware-based first platform configurationregisters, the one or more hardware-based first platform configurationregisters configured to store boot measurement data values associatedwith a boot sequence implemented by the first processing device; asecure element, the secure element including a second processing deviceand one or more hardware-based second platform configuration registers;and an authenticated communications interface coupling the one or morehardware-based first platform configuration registers and the one ormore hardware-based second platform configuration registers together,the authenticated communications interface being a physically fixedcommunications interface, the authenticated communications interfaceadapted to copy the boot measurement data values, as each bootmeasurement data value is generated, between the one or morehardware-based first platform configuration registers and the one ormore hardware-based second platform configuration registers, whereinboth the first processing device and the secure element are contained ina single computing device, wherein the copying maintains the bootmeasurement data values in the one or more hardware-based first platformconfiguration registers and the one or more hardware-based secondplatform configuration registers, wherein the secure element is adaptedto generate a digital signature for authenticating a financialtransaction, said digital signature generated by cryptographicallysigning the boot measurement data values copied to the one or morehardware-based second platform configuration registers, and used toverify the integrity of the boot sequence implemented by the firstprocessing device.
 2. The circuit of claim 1, wherein the secure elementis adapted to implement a cryptographic function to authenticate a userof the circuit.
 3. The circuit of claim 1, wherein the one or more firstplatform configuration registers are arranged in a trusted executionenvironment of the first processing device.
 4. The circuit of claim 1,further comprising: a memory to store a first software applicationadapted to verify the integrity of the boot sequence based on the bootmeasurement data values.
 5. The circuit of claim 4, wherein the secureelement comprises: a memory to store a second software applicationadapted to facilitate transmission of the boot measurement data valuesto the first software application.
 6. The circuit of claim 4, furthercomprising: one or more drivers to facilitate transmission of the bootmeasurement data values to the first software application.
 7. Thecircuit of claim 1, wherein the secure element is adapted tocryptographically sign at least one of the boot measurement data valuesand to provide the cryptographically signed at least one of the bootmeasurement data values to a requesting element.
 8. The circuit of claim7, wherein the secure element comprises: a memory to store a thirdsoftware application executable by the second processing device, thethird software application adapted to cryptographically sign the atleast one of the boot measurement data values.
 9. The circuit of claim1, wherein the first processing device or the secure element is adaptedto authorize or refuse a transaction based on at least one of the bootmeasurement data values.
 10. The circuit of claim 1, wherein the circuitis arranged within a smartphone.
 11. A method to verify integrity of aboot sequence, comprising: implementing a boot sequence by a firstprocessing device; storing, within a first set of hardware-basedplatform configuration registers of the first processing device, atleast one data value representative of boot measurements generatedduring the boot sequence; upon generation of each boot measurement,maintaining the at least one data value in both the first set ofhardware-based platform configuration registers and a second set ofhardware-based platform configuration registers of a secure element bytransferring the at least one data value from the first set ofhardware-based platform configuration registers to the second set ofhardware-based platform configuration registers of the secure elementvia an authenticated, physically fixed communications interface thatcouples together the first and second sets of hardware-based platformconfiguration registers, the secure element having a second processingdevice, wherein both the first processing device and the secure elementare contained in a single computing device; and generating a digitalsignature for authenticating a financial transaction, said digitalsignature generated by cryptographically signing the at least one datavalue transferred to the second set of hardware-based platformconfiguration registers, and used to verify the integrity of the bootsequence implemented by the first processing device.
 12. The method ofclaim 11, further comprising: requesting, by a first softwareapplication, the at least one data value; cryptographically signing theat least one data value by the secure element; and providing, by thesecure element, the cryptographically signed at least one data value tothe first software application.
 13. The method of claim 12, furthercomprising: verifying, by the first software application, integrity ofthe boot sequence based on the at least one data value.
 14. The methodof claim 12, further comprising: communicating the cryptographicallysigned at least one data value to the first software application via asecond software application.
 15. The method of claim 11, furthercomprising: temporarily storing the at least one data value; loading atrusted execution environment, the first set of platform configurationregisters associated with the trusted execution environment; copying thetemporarily stored at least one data value into the first set ofplatform configuration registers.
 16. The method of claim 11, whereinthe boot sequence includes booting a smartphone.
 17. The method of claim11, further comprising: sequentially generating additional data valuesrepresentative of additional boot measurements generated during the bootsequence.
 18. A system, comprising: a first set of hardware-basedplatform configuration registers; a second set of hardware-basedplatform configuration registers; an authenticated communicationsinterface coupling the first set of hardware-based platformconfiguration registers and the second set of hardware-based platformconfiguration registers together, the authenticated communicationsinterface being a physically fixed communications interface; a secureelement associated with the second set of hardware-based platformconfiguration registers, the secure element configured to perform acryptographic operation on data stored in the second set ofhardware-based platform configuration registers; and a first processingdevice associated with the first set of hardware-based platformconfiguration registers and communicatively coupled to the secureelement, the first processing device configured to store bootmeasurement data values associated with a boot sequence in the first setof hardware-based platform configuration registers, wherein the bootmeasurement data values are chained to form a digest of measurementsrepresentative of the boot sequence, wherein both the first processingdevice and the secure element are contained in a single computingdevice, wherein the system is configured to transfer the bootmeasurement data values as each boot measurement data value is generatedto maintain the boot measurement data values in both the first andsecond sets of hardware-based platform configuration registers, whereinthe secure element is adapted to generate a digital signature forauthenticating a financial transaction, said digital signature generatedby cryptographically signing the boot measurement data valuestransferred to the second set of hardware-based platform configurationregisters, and used to verify the integrity of the boot sequenceimplemented by the first processing device.
 19. The system of claim 18,wherein the system includes components of a smartphone.
 20. The systemof claim 18, wherein the first processing device is further configuredto pass at least some of the boot measurement data values to the secureelement for storage in the second set of platform configurationregisters.